ii !i urn ii mini 

(H) EP1 211 598 A1 

(1 2) EUROPEAN PATENT APPLICATION 

(43) Date of publication: (51) | ntC l7: G06F 9/45 

05.06.2002 Bulletin 2002/23 

(21) Application number: 00403344.5 



(22) Date of filing: 29.11.2000 



(84) Designated Contracting States: 


• Lesot, Jean Phillippe 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


35370 Etrelles (FR) 


MC NL PT SE TR 


• Banatre, Michel 


Designated Extension States: 


35111 La Fresnals (FR) 


AL LT LV MK RO SI 


• Routeau, Jean-Paul 




35235 Thorigne Foulllard (FR) 


(71) Applicants: 


• Parrain, Frederic 


• Texas Instruments Incorporated 


35000 Rennes (FR) 


Dallas, Texas 75251 (US) 


• Issarny, Valerie 


Designated Contracting States: 


78800 Houilles (FR) 


BE CH DE DK ES Fl GB GR IE IT LI LU MC NL PT 


• Hlguera, Teresa 


SE TR AT CY 


75016 Paris (FR) 


• TEXAS INSTRUMENTS FRANCE 


• Chauvel, Gerard 


06271 Villeneuve Loubet Cedex (FR) 


292 Chemin du Valbosquet, 06600 Antibes (FR) 


Designated Contracting States: 


• D'lnverno, Dominique 


FR 


06270 Vllleneuve-Loubet (FR) 


• Instltut National de Recherche en Informatique 


• Lassere, Serge 


et en Automatique INRIA 


Lieudit St Jean de Cannes, 83600 Frejus (FR) 


35042 Rennes Cedex (FR) 




Designated Contracting States: 


(74) Representative: Potter, Julian Mark et al 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


D. Young & Co., 


MC NL PT SE TR 


21 New Fetter Lane 




London EC4A 1 DA (GB) 


(72) Inventors: 




• Cabillac, Gilbert 




35230 Noyal Chatillon Sur Seine (FR) 





(54) Data processing apparatus, system and method 



Europalsches Patentamt 
^ 1 - - 1 /fill European Patent Office 

Office europeen des brevets 



00 

in 



CM 



(57) A method for generating program code for 
translating high level code into instructions for one of a 
plurality of target processors comprises first determining 
a desired program code characteristic corresponding to 
a target processor. Then, selecting one or more prede- 
fined program code modules from a plurality of available 
program code modules in accordance with said desired 
program code characteristic, and generating program 
code for translating high level code into instructions for 
said target processor from said selected one or more 
predefined program code modules. Preferably, the 
method comprises forming agglomerated program code 
from a plurality of program code modules in accordance 
with said desired program code characteristic. 
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Description 

[0001] The present invention relates to a data 
processing apparatus, system and method for generat- 
ing program code for translating high level code into in- 
structions for one or more target processors and, sepa- 
rately, to a data processing apparatus system and meth- 
od for running such program code. In particular, but not 
exclusively, the program code forms a virtual machine, 
for example a JAVA virtual machine, for the one or more 
target processors. 

[0002] It is becoming more and more common for a 
variety of appliances and electronic goods to include 
processing devices embedded within them to provide a 
high level of functionality forthe appliance. For example, 
embedded processing devices may be found in such 
disparate appliances as mobile 'phones, TV set top box- 
es, pagers, coffee makers, toasters, in-car systems, ve- 
hicle management control systems and personal digital 
assistants (PDAs), to name but a few. The market for 
embedded processing devices is growing extremely 
fast, in particular new applications and hardware archi- 
tectures are appearing on an almost daily basis. 
[0003] With regard to applications, multi-media appli- 
cations are now necessary for wireless devices, set-top 
boxes or screen 'phones, amongst other things. More- 
over, wireless products have introduced a need for new 
kinds of applications such as new communication pro- 
tocols (UMTS), ad hoc networks or neighbourhood in- 
teraction protocols based on blue tooth technology, for 
example. Other applications will be readily recognised 
by the ordinarily skilled person. 
[0004] Furthermore, hardware architectures for em- 
bedded processing devices are constantly being devel- 
oped since there is an increasing need for computation 
capacity, as well as other requirements such as safety- 
critical systems, autonomy management and power 
saving features. 

[0005] Another feature of embedded devices is that 
they are often one of a plurality of processing devices 
which form an embedded processing system. Such em- 
bedded systems are useful for complex applications 
such as multi-media applications. 
[0006] In order to aid application development, and to 
re-use applications to run on different host processors, 
it is desirable that the application code is transportable 
between different host processors. This provides for re- 
use of whole applications, or parts thereof, thereby in- 
creasing the speed of development of applications for 
new processors and indeed increasing the speed of de- 
velopment of new applications themselves. This may be 
achieved by means of program code which runs on a 
host processor and is capable of translating high level 
program code into operation code or instructions forthe 
host processor. The program code provides a virtual 
machine for a host processor, enabling it to implement 
application software written in an appropriate high level 
language. An example of such translating program code 



is the JAVA programming language developed by Sun 
Microsystems, Inc. (JAVA is a trademark of Sun Mi- 
crosystems, Inc). Such program code, when running on 
an appropriate host processor is known as a JAVA Vir- 

5 tual Machine. 

[0007] Although examples of embodiments of the 
present invention will be described with reference to 
JAVA and JAVA Virtual Machines, embodiments in ac- 
cordance with the invention are not limited to the JAVA 

10 programming language but may be implemented using 
other suitable programming languages for forming vir- 
tual machines. 

[0008] A feature of a virtual machine is that it provides 
for the dynamic loading of applications onto embedded 
is processing systems. This is an extremely useful feature. 
Typically, applications are already embedded within a 
processing system. It is difficult to dynamically down- 
load an application or to patch an existing application 
onto an embedded processing device. However, virtual 
machines, such as JAVA, provide the possibility of en- 
abling dynamic loading of a complete application that 
could be written by a third party and available on a re- 
mote server, for example. Moreover, distribution and 
maintenance costs are reduced since it is possible to 
dynamically interact with the embedded system via the 
virtual machine. Due to JAVA application program inter- 
faces APIs standardisation, the configuration and the 
profiles, reference [1], for compatibility of applications 
can be ensured if the JAVA platform on the embedded 
system Is compliant with the standardisation. 
[0009] Security features are also available within 
JAVA to identify a trusted code which is dynamically 
downloaded through a network and to preserve the 
availability of the embedded system. 
[0010] Another feature of JAVA is that the hardware 
architecture heterogeneity management may be 
masked. A major advantage of such a feature is that it 
reduces the software development costs of an applica- 
tion. Embedded processors typically are highly diverse 
and have specific capabilities and capacities directed to 
the needs of the system or appliance In which they are 
embedded. This would generally give rise to a high cost 
of application development. However, because of the 
portable nature of JAVA code between JAVA Virtual Ma- 
chines, the cost of integrating a new hardware architec- 
ture, for example, merely relies on developing a new 
JAVA Virtual Machine. Another important feature is that 
the transparent exploitation of a multi-processor archi- 
tecture can be achieved by a JAVA Virtual Machine, 
without any change of the application code. 
[0011] Two known JAVA virtual machines are the 
JWORKS [6] and KVM, the JAVA virtual machine of 
J2MF [7]. JWORKS is part of personal JAVA virtual ma- 
chine distribution on VXWORKS real-time operating 
systems. As VXWORKS is designed to be integrated on 
a large range of hardware platforms and because 
JWORKS is, at least from the operating system point of 
view, an application respecting VXWORKS APIs, 
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JWORKS could be executed on a large range of hard- 
ware platforms. Nevertheless, the integration of 
JWORKS on a new embedded system is limited to the 
VXWORKS porting ability, without any consideration of 
the JAVA virtual machine. However, as will be described 
in detail later, a JAVA virtual machine must take care of 
many different aspects. In light of this, JWORKS is un- 
able to provide the best trade-off for a dedicated embed- 
ded system, since it does not take into account the dif- 
ferent requirements of target host processors In the em- 
bedded system. 

[0012] J2ME is a Sun Java platform for small embed- 
ded devices. KVM is the JAVA virtual machine of J2ME. 
It supports 16 and 32 bits CISC and RISC processors, 
and generates a small memory footprint and can keep 
the code in a memory area of about 1 28 KB. It is written 
for a ANSI C compiler with the size of basic types well 
defined (e.g. character on 8 bits, long on 32 bits). This 
is why it is difficult to port the KVM onto another compiler 
(for example the Tl DSP C55x C family compilers sup- 
port characters on 16 bits), without re-writing all the 
JAVA virtual machine. Additionally, an optional data 
alignment can only be obtained for 64 bit data. Other 
alignments are handled by the C compiler. Moreover, 
there is no possibility to manage a heterogeneous mul- 
tiprocessor without re-writing C structures (due to data 
representation conversion). It is also not possible to tune 
a trade-off between memory and access costs without 
re-writing substantially all the parts of the JAVA virtual 
machine. 

[0013] A problem with the increasing development of 
new hardware architectures for embedded devices is 
that it is necessary to continually develop new virtual 
machines for the new devices. In principle, a virtual ma- 
chine designed to run in accordance with a particular 
operating system might well be capable of being used 
on different host processing devices utilising that oper- 
ating system, it is generally the case that the different 
generations of hardware architecture mean that a virtual 
machine for one processor is not optimised for another 
host processing device. Consequently, in order to pro- 
vide the greatest capabilities and efficiencies from a 
host processor, a virtual machine needs to be designed 
for each target processor. This increases the cost and 
delays incorporating new processing devices into em- 
bedded systems. 

[001 4] Viewed from one aspect, the present invention 
teaches how to build a virtual machine (JAVA Virtual Ma- 
chine) which may be compatible for several embedded 
systems. In this regard, the Virtual Machine comprises 
program code modules, each module providing a par- 
ticular function and optimised for a particular host proc- 
essor. 

[0015] Viewed from another aspect, the invention 
teaches and provides an environment for designing a 
virtual machine in a modular manner, to permit its adap- 
tation to a plurality of processing devices and, therefore, 
embedded systems, by taking into account several cri- 



teria such as memory size, available processor facilities 
and functions or performance issues. 
[0016] A virtual machine in accordance with, or de- 
signed in accordance with, the foregoing provides for 
5 the prompt and speedy development of virtual machines 
optimised for one, or possibly more than one, target host 
processor in order to achieve an optimum trade-off be- 
tween all the different components of the embedded 
system. 

10 [0017] In accordance with one aspect of the present 
invention, there is provided a method for generating pro- 
gram code for translating high level code into instruc- 
tions for a target processor, the method comprising: 

15 determining a program code characteristic in ac- 
cordance with a target processor; 
deriving one or more program code modules in ac- 
cordance with said program code characteristic; 
and 

20 generating program code for translating high level 
code Into instructions for said target processor from 
said one or more program code modules. 

[0018] Such program code may be generated from an 
25 agglomeration of said plurality of program code mod- 
ules. 

[0019] In another aspect, the present invention pro- 
vides a software tool for creating program code for trans- 
lating between high level code and instructions for a tar- 
30 get processor, comprising software tool elements for: 

determining a program code characteristic in ac- 
cordance with a target processor; 
deriving one or more program code modules in ac- 
cordance with said program code characteristic; 
and 

forming program code for translating high level 
code into instructions for said target processor from 
said one or more program code modules. 

[0020] A method or software tool in accordance with 
the foregoing advantageously generates modular pro- 
gram code for translating high level code into instruc- 
tions for a target processor. Thus, modules can be de- 
rived separately, and optimised separately for the target 
processor. 

[0021] Suitably, deriving one or more program mod- 
ules is achieved by selecting one or more predefined 
program code modules in accordance with the program 
code characteristic from a plurality of available prede- 
fined program code modules. 
[0022] A method or software tool in accordance with 
the foregoing paragraph provides the advantage that 
program code for translating high level code into instruc- 
tions for a target processor, i.e. a virtual machine, may 
be easily developed by using suitable program code 
modules from a library of program code modules. This 
obviates the need for a virtual machine to be desired 
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from scratch for each net target host processor, thereby 
speeding up development of such virtual machine. Fur- 
thermore, because code is being re-used there are likely 
to be fewer problems or bugs in the program code for 
the new virtual machine, thereby increasing its robust- 
ness. 

[0023] Preferably, the selection of said desired pro- 
gram code modules is in accordance with a desired 
functionality for said target processor. Thus, program 
code modules are selected in order to create a virtual 
machine capable of supporting and optimising particular 
functions for an application to be run on the target proc- 
essor. 

[0024] In yet another aspect of the invention, there is 
provided data processing apparatus for creating pro- 
gram code for translating between high level code and 
instructions for a target processor, the data processing 
apparatus being configured to: 

determine a program code characteristic in accord- 
ance with a target processor identifier input to said 
data processing apparatus; 
derive one or more program code modules in ac- 
cordance with said program code characteristic; 
and 

create program code for translating high level code 
into instructions for said target processor from said 
one or more program code modules. Such data 
processing apparatus provides a suitable environ- 
ment for implementing the method and/or software 
tool as described in the foregoing paragraphs. 

[0025] In a preferred embodiment, respective pro- 
gram code characteristics are determined for respective 
ones of a plurality of target processors, program code 
modules are derived in accordance with said respective 
program code characteristics, and program code for 
translating high level code into instructions for said tar- 
get processors is generated from said program code 
modules. 

[0026] Suitably, program code is generated for trans- 
lating high level code into instructions for one of a plu- 
rality of target processors. 

[0027] An advantage of the preferred embodiment is 
that program code can be generated capable of operat- 
ing for more than one target processor, yet comprising 
individual modules for respective target processors 
thereby providing for optimisation of modules, and 
hence the program codes for individual target proces- 
sors. 

[0028] In a still yet another aspect of the invention, 
there is provided program code comprising at least one 
program code module of a plurality of program code 
modules for translating between high level code and in- 
structions for a target processor, said at least one pro- 
gram code module being in accordance with a charac- 
teristic of said target processor and selected from said 
plurality of program code modules. 



[0029] The program code may comprise at least two 
program code modules for translating between high lev- 
el code and instructions for respective ones of at least 
two target processors. 

5 [0030] Typically, the program code comprises an ag- 
glomeration of two or more program code modules. 
[0031] In a still yet further aspect of the invention, 
there is provided a processor, configured in accordance 
with program code comprising at least one program 

10 code module of a plurality of program code modules, for 
translating between high level code and instructions for 
a target processor, said at least one program code mod- 
ule being selected from said plurality of program code 
modules in accordance with a characteristic of said tar- 

15 get processor. 

[0032] Typically, the processor is configured by pro- 
gram code comprising an agglomeration of two or more 
program code modules of said plurality of said program 
code modules. 

20 [0033] In a still yet further aspect of the invention there 
is provided a system comprising a first and second proc- 
essor, said first and second processor configured in ac- 
cordance with program code comprising at least two 
program code modules, wherein a first of said at least 

25 two program code modules is arranged to translate high 
level code to instructions for said first processor and a 
second of said at least two program code modules is 
arranged to translate high level code to instructions for 
said second processor. 

30 [0034] Embodiments of the present invention provide 
development of virtual machines, for example JAVA vir- 
tual machines using modular adaptability such that it is 
possible to support in a straight forward manner any kind 
of data representation on a target processor or proces- 

35 sors. Additionally, language mapping can be added to 
the development environment for supporting different 
compilers. Furthermore, each module can define its own 
data alignment as well as also introducing transparent 
data representation conversion to support heterogene- 

40 ous architecture. The user memory may also be opti- 
mised. 

[0035] Embodiments in accordance with the present 
invention provide a new methodology and apparatus to 
design and implement a virtual machine for embedded 

45 systems, in particular systems including different proc- 
essors. The methodology based on modularity specifi- 
cation and implementation in accordance with aspects 
of the invention provide aflexibility in design possibilities 
with regard to a particular module without needing to re- 

50 considerthe implementation of the other modules. Mod- 
ularity also facilitates the adaptation of a virtual machine 
for other embedded systems. 

[0036] Embodiments of the present invention are dis- 
tinguished from conventional porting of virtual machines 
55 onto different hardware since porting of a virtual ma- 
chine does not give the best results for a new or multi- 
processor since the trade-off between performance, 
memory and energy are best specific to a target proc- 
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essor. Advantageously, the modular approach of em- 
bodiments of the present invention permit the adapta- 
tion of each module of the virtual machine and experi- 
mentation for each one, in orderto evaluate whether the 
trade-off is acceptable from the point of view of the vir- 
tual machine design criteria. 

[0037] Particular preferred aspects of the invention 
are set out in the accompanying independent claims. 
Combinations of features from the dependent and/or in- 
dependent claims may be combined as appropriate, not 
merely as set out in the claims. 
[0038] Preferred embodiments in accordance with the 
present invention will now be described, by way of ex- 
ample only, and with reference to the accompanying 
drawings, in which:- 

Figure 1 is a schematic illustration of a multi-proc- 
essor; 

, Figure 2 is a flow diagram illustrating the process 
for implementing an application using a JAVA virtual 
machine; 

Figure 3 is a schematic illustration of a development 
environment in accordance with an aspect of the in- 
vention; 

Figure 4 is a table; and 
Figure 5 is a table. 

[0039] The following illustrative examples of embodi- 
ments of the invention will be described with reference 
to JAVA and JAVA Virtual Machines. However, embod- 
iments of the invention are not limited to JAVA program- 
ming languages or virtual machines. 
[0040] A JAVA Virtual Machine allows an embedded 
processing system to be abstracted out of the embed- 
ded system as far as an application programmer is con- 
cerned. However, this means that a JAVA Virtual Ma- 
chine has to take Into account different aspects of an 
embedded processor system, such as the hardware ar- 
chitecture, the tool chain available for the hardware, the 
hardware operating system as well as the application 
requirements. 

[0041] The integration of these four different aspects 
represents a significant challenge in design and imple- 
mentation of a JAVA Virtual Machine since there are 
many options and choices which may be taken for ab- 
stracting the different aspects of the embedded 
processing system, to arrive at a solution to a particular 
embedded processing system. 
[0042] A first consideration is the hardware of the tar- 
get processing device. Typically, an embedded system 
comprises, amongst other things, one or more core 
processors, a memory architecture and typically some 
energy aware features. 

[0043] Figure 1 illustrates an embodiment of a multi- 
processor system 100, suitable for providing a platform 
for a virtual machine in accordance with an embodiment 
of the present invention. The mutti-processor system 
1 00 illustrated in Figure 1 is a simplified schematic illus- 



tration of a processor for ease of explanation. System 
100 may comprise a general purpose processor, a dig- 
ital signal processor (DSP), and a hardware processor 
optimised forprovidingavirtual machine platform forex- 

5 ample. Other compbinations or devices may be used. 
The basic elements of processor system 1 00 are a level 
3 traffic input/output bus and interface 102 which pro- 
vides an interface between external memory 1 04 and 
various functional units on the processor system 100. 

10 For example, the input/output bus and interface 102 is 
in communication with LCD display controller 110 and 
hence display 1 1 2, and a level 2 traffic bus 1 03. Level 3 
traffic bus 1 02 is also in communication with access cir- 
cuitry 111 for multi-processor system 100. Information 

1* from an external source such as external memory 104 
is provided via interface 102 to provide processor in- 
structions for example. Additionally, data may be provid- 
ed from external memory 1 04 via interface 1 02 and over 
bus 103. Virtual machine instructions from the external 

20 memory 1 04 may be communicated over bus 1 02 and 
103 and cached in cache unit 1 06 of the separate proc- 
essor units 114a, 114b, 114c. From cache 106 instruc- 
tions are loaded into an instruction buffer for input to the 
processor units 114. 

25 [0044] A processor system 100, as illustrated in Fig- 
ure 1 , may be embedded in a system such as for a do- 
mestic appliance or may be the central processing unit 
of a computer system, for example. In this regard, em- 
bodiments of the present invention are not limited to em- 

30 bedded processing systems, nor to muiti -processor sys- 
tems. 

[0045] Each processor may define its own data rep- 
resentation capabilities, for example from 8 bits to 128 
bits and possibly more in future processing devices. For 

35 efficient operation, a JAVA Virtual Machine must be ca- 
pable of manipulating byte code which is adapted for the 
particular data representation of the target processor. 
The availability of a floating point support such as 32- 
or 64-bit floating point in a processor may also be utilised 

40 by JAVA Virtual Machine to implement the float or dou- 
ble JAVA data types. Additionally, the registers available 
in a target processor may be exploited, or at least a sub- 
set of them, to optimise JAVA stack performance. For 
example, one register can be used for the representa- 

45 tion of the JAVA stack pointer. Another consideration of 
the hardware architecture is the memory alignment is- 
sues, for example whether it is constant, proportionate 
to size, proportioned with threshold or some other such 
criterion. Additionally, the memory access cost has to 

so be taken into account in order to efficiently arrange ob- 
ject fields within the JAVA interface. Furthermore, if the 
embedded system comprises a multi-processor system, 
then the existence of homogenous or heterogeneous 
data representation (/ENDIAN) data size alignment has 

35 to be correctly managed in order to share JAVA objects 
or internal JAVA Virtual Machine data structures be- 
tween the different processors in the multi-processor 
system. 
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[0046] An embedded system may well have many dif- 
ferent types of memories, for example RAM, DRAM, 
FLASH, local RAM, which have to be taken into account 
as regards their particular performance characteristics. 
Additionally, the size of each memory has to be consid- 
ered. For example, a local variable pool can be stored 
in local RAM whilst class files may be arranged in 
FLASH memory. Another consideration is that with a 
shared memory multi-processors, the JAVA Virtual Ma- 
chine must manage homogenous or heterogeneous ad- 
dress space to correctly share JAVA objects or JAVA Vir- 
tual Machine internal structure. The cache architecture, 
such as whether it has one or two levels or a particular 
type of flash, must also be taken into account in order 
to properly Implement JAVA synchronisation and the 
volatile attributes of an object field. 
[0047] For mobile or portable applications, an impor- 
tant aspect of the processor system is the use by the 
JAVA Virtual Machine of energy aware instruction sets 
such that the byte code generated for the JAVA Virtual 
Machine minimise the system energy consumption. 
[0046] Another aspect for consideration is that proc- 
essors, or families of processors, are typically associat- 
ed with a tool chain. A tool chain provides a series of 
functions and processes implemented in the target proc- 
essors instruction code which may be called via a JAVA 
Virtual Machine. Typically, each hardware platform 
makes various languages available for implementation 
upon it, for example C++, optimised C or assembler, 
which can realise optimisations about memory con- 
sumption, use of an optimised instruction set, pre-proc- 
essor code optimisation and the use of register, Inlining 
calls, 64 bit support amongst other things. Whilst it is 
evident that the use of a ANSI C compiler would in- 
crease the portability of an implementation, it should be 
borne in mind that other languages are available for 
hardware platforms. The particular capabilities of a com- 
piler, as provided by their tool chain, may be implement- 
ed within a JAVA Virtual Machine for that processor. 
[0049] Another aspect which needs to be considered 
when developing a JAVA Virtual Machine for a target 
processor/s, is the operating system that the target sys- 
tem runs under. Generally, an operating system has 
some good and some bad properties and, consequently, 
may be better for certain types of embedded system and 
not others. Particularly, operating systems tend to be de- 
signed to address a particular type of application and 
use. For example, POSIX operating systems such as 
LINUX, WINCE, SYMBIAN, are designed for general 
applications, a real-time operating system such as VX 
WORKS, NUCLEUS, and RTEMS are designed for real- 
time applications and dedicated processor kernel oper- 
ating systems such as DDP BIOS SPOX, PALM OS for 
specific embedded applications or digital signal 
processing. Each of the foregoing operating systems 
and applications have differences which impact upon 
the implementation of a JAVA application program inter- 
face. For example, to be compliant to RTSJ reference 



[2] a real-time operating system should be used. 
[0050] A further aspect to be considered is the appli- 
cation requirements for processing systems. This is par- 
ticularly important for an embedded system which would 
s typically be directed to a particular type of application. 
As is well-known, a JAVA application requires the use 
of JAVA application program interfaces. Depending up- 
on application needs, several application program inter- 
faces have been defined, for example J2MF for embed- 
10 ded devices and J2SE for desk-top computers. A JAVA 
Virtual Machine has to provide, or not, the relevant ap- 
plication program interfaces to support, or not, a com- 
pliant application. Additionally, new processor devices 
can be masked through application program interfaces 
is and, therefore, a JAVA Virtual Machine needs to be able 
to deal with low-level implementations of the devices. 
An example would be a JAVA Virtual Machine support- 
ing a blue tooth communications network protocol for 
which an appropriate application program interface 

20 would have to be defined. Application program interfac- 
es are not necessarily the sole preserve of the applica- 
tion programmer, but may well be the result of standard 
specifications such as may be derived by a JAVA com- 
munity process group. 

2$ [0051] Figure 2 illustrates the process flow for imple- 
menting an application using a JAVA Virtual Machine. 
The process starts at step 120 where an application in 
JAVA source code is developed and written. That appli- 
cation source code is compiled in a JAVA compiler at 

30 step 1 22 which converts the application source code in- 
to an architecture neutral object file format thereby en- 
coding a compiled instruction sequence at step 124, in 
accordance with the JAVA Virtual Machine specification. 
The compiled instruction sequence at step 124 consists 

35 of a plurality of byte codes. The byte codes are executed 
by the JAVA Virtual Machine at step 125, which trans- 
lates the byte codes Into processor instructions for im- 
plementation on processor 100 at step 128. 
[0052] As discussed above, a large number of criteria 

^0 have to be taken into account when designing a JAVA 
Virtual Machine for embedded processing systems. The 
design of a JAVA Virtual Machine is complex, particular- 
ly if certain goals are to be achieved. Namely, those 
goals are to minimise the importing cost of the JAVA Vir- 

^5 tual Machine onto a new embedded processing system; 
to obtain the best trade off between application needs, 
embedded system processing constraints and embed- 
ded system features; and to adapt the JAVA Virtual Ma- 
chine to features of new hardware and new applications. 

so [0053] The present applicant has addressed the prob- 
lems and difficulties encountered in developing JAVA 
Virtual Machines to meet the foregoing design criteria 
by developing a modular JAVA Virtual Machine architec- 
ture. The term "modular" means at least two associated 

55 things. Firstly, it refers to a specification of all individual 
different software parts for a JAVA Virtual Machine and, 
secondly, a way to agglomerate these many parts, writ- 
ten In separate languages, with maximum transparency 
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in order to provide a modularised environment for gen- 
erating a modular JAVA virtual machine. Additionally, 
the applicant has invented an architecture in which it is 
possible to transparently access a particular module 
from other modules. Consequently, the architecture pro- 
vides for the investigation of several implementation 
choices for a module for one specific embedded system 
by testing the implementation system with regard to oth- 
er modules and best design choice. The choice of im- 
plementation may be done in accordance with different 
features of the embedded system such as its hardware 
architecture, its tool chain, operating system and appli- 
cation requirements. 

[0054] By designing and implementing a modular 
JAVA Virtual Machine, the JAVA Virtual Machine may be 
implemented for a particular embedded system. And the 
trade-off between the various attributes of the system 
can be optimised for the particular target processors and 
application. 

[0055] Referring now to Figure 3, there is illustrated 
an example of a development environment such as may 
be provided by a software tool, for developing a modular 
JAVA Virtual Machine (MDE). The MDE 200 provides a 
series of tools to support the modular design of a JAVA 
Virtual Machine. Three inputs are sent to the MDE in 
order to generate the sources and glues. First, an inter- 
face definition language (IDL) specification 204 which 
describes declarations of JAVA Virtual Machine services 
and types utilising a processor independent language is 
input. Additionally, various program code modules con- 
taining implementations of JAVA Virtual Machine serv- 
ices and types for one of a number of languages which 
can be run on target processors can be input. Finally, 
alignment definitions 208 describing the alignment con- 
straints for different target processors, together with 
their respective access costs are also input to MDE 200. 
[0056] A tool chain 210 compiles sources and glues 
212 to generate program code to form a JAVA Virtual 
Machine suitable for the processing device or specific 
embedded system for which the JAVA Virtual Machine 
is targeted. The tool chain 21 0 generates a JAVA virtual 
machine for each processor of a multi-processor sys- 
tem. Each JAVA virtual machine comprises its own mod- 
ules, and preferably does not share modules with other 
JAVA virtual machines. In this regard, each JAVA virtual 
machine is independent of the other. The choice of mod- 
ules for each JAVA virtual machine depends on the de- 
sign criteria input 220. 

[0057] Describing the specification for the modular 
JAVA Virtual Machine interface definition language 204 
in more detail, the IDL describes services and datatypes 
independently of the language implementation of the 
JAVA Virtual Machine. The service comprises a function 
name with a return type and all data types used for that 
service and the direction of its parameters. The type it- 
self is composed of other types or structured types such 
as structures, unions and arrays, with services to create 
and free instances of the type and parameters to initial- 



ise such instances. 

[0058] The implementation modules, 206, each com- 
prise service or type implementations having common 
or shared implementation characteristics or knowledge. 

5 When a particular module M1 , M2, M3 or M4 is selected 
to be part of the JAVA Virtual Machine, all services and 
type implementations inside the selected module are al- 
so selected. A scheduler module is also included as part 
of the implementation modules 206. The scheduler 

10 module undertakes load balancing to determine wheth- 
er a task is mapped to a particular one or other of a plu- 
rality of processing devices in an embedding system, e. 
g. DSPorMPU. 

[0059] A module, M1.M2, M3orM4, may fully or par- 
's tially implement the service, as well as supplying pre/ 
post hooks and wrappers as described hereinafter. 
[0060] Pre-hooks are functions executed just before 
functions which implement a service. Prepare functions 
have to return all module agree or not on the executed 
20 service. Whereas commit functions execute only if all 
prepare functions from all module agree to execute the 
service. If not, then abort functions are executed. 
[0061] Post-hooks are functions which are executed 
just after functions to implement the service. Post func- 
25 tions are executed only if the function that implements 
the service does not return an error. If an error is re- 
turned, then error functions are executed. 
[0062] Wrappers are functions which are executed in 
place of a service. It is the wrappers 1 responsibility of 
30 calling the original service, if desired, and also to modify 
parameters and return values for the service. 
[0063] A module can add a private part to any type 
defined for it, as well as initialisation and destruction 
functions. A private part could be an opaque type such 
35 as a memory area which is only managed by the mod- 
ule, another defined type or a structural type with a fixed 
or variable size. 

[0064] The modular development environment 200 
comprises three main components: the module chooser 

40 214, the type manager 21 6 and several language map- 
pings 218. In order to be able to generate different as- 
pects or versions of a JAVA Virtual Machine for different 
target host processors within a multi-processor system, 
several different modules are configured to implement 

45 the same services and types, yet for different processor 
languages. In this case, each module is described by a 
set of keywords. The module chooser 214 selects from 
the plurality of modules M1, M2, M3 and M4 the most 
accurate one or ones for a specific embedded process- 

50 jng system in accordance with design criteria 220 input 
thereto. The design criteria comprises a list of weighted 
keywords. 

[0065] The role of the type manager 21 6 is to merge 
different parts of a type, whether global or private, to a 
55 module and to generate offset of its different compo- 
nents according to alignment constraints on one or sev- 
eral target processors as input from alignment definition 
208. Language mapping module 21 8 provides different 
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language mapping for generating sources and gtues. 
The language mapping to generate sources and glues 
is performed off-line and therefore there is no overhead 
in managing services, hooks, wrappers and fixed size 
types. 

[0066] In an illustrative implementation, the MDE 200 
comprises two parts which read the specification IDL 
and implementation description files. In addition, there 
is the module chooser for receiving inputs in respect of 
design criteria, specification interface definition lan- 
guage criteria and implementation modules. Two type 
managers are provided. The first one handles only align- 
ment constraints for mono- and multi-processors. The 
other type manager is configured to aggressively mini- 
mise memory consumption. Optionally, a third type 
manager may be included configured to tune a trade-off 
between memory consumption and access cost. 
[0067] In the illustrated embodiment, language map- 
ping module 218 comprises two language mappings. 
One for GNU-C and GNU-tool chains. The other is for 
Texas Instruments C and its corresponding tool chain. 
It will be evident to a person of ordinary skill in the art 
further language mapping elements may be included to 
integrate other assembler languages. 
[0068] Each module of the JAVA virtual machine may 
be of a so-called open design. Examples of module de- 
sign addressing the four different points described 
above in relation to hardware through to application re- 
quirements will now be described. Extensions to module 
designs are described for each point. 
[0069] An individual module design could be config- 
ured to compensate for lack of features of a particular 
target processor, or to optimise an implementation or to 
exploit features supported by the hardware. For exam- 
ple, since there is no direct use of compiler basic types 
it is possible to implement missing types, for example 
implement 64-bit integer support, for a hardware where 
such type are not supported. Additionally, structures are 
not managed by the compiler, but the MDE. Therefore, 
well aligned structures compatible with several core tar- 
get processors may be generated, as well as the rear- 
rangement of the structure organisation to minimise 
memory consumption. The trade-off between memory 
consumption and access cost may also be managed. 
For example, due to the high frequency of object struc- 
ture access, the access cost objects is very important 
to optimise. 

[0070] A software tool in accordance with an embod- 
iment of the invention can be utilised by an implementer 
to write special modules to efficiently use a hardware's 
potential for a target processor. For example, a dedicat- 
ed stack module could use a local doubie access mem- 
ory or chip to optimise the performance of the energy 
consumption of the JAVA virtual machine. 
[0071] Adding a new tool chain may be achieved by 
adding a new language mapping in the MDE. Thus, new 
language support may be added, for example an as- 
sembler for a specific target processor, or the JAVA lan- 



guage itself in connection with a native interface sup- 
port. Similarly, it can be possible to exploit or compen- 
sate for a tool chain or compiler features, e.g. lining sup- 
. port. 

s [0072] Operating system compatibility is derived from 
the specification of services for operating system func- 
tionalities. An implementation of these services is oper- 
ating system dependent, and therefore has to be re-writ- 
ten for each incompatible operating system application 
io programme interface.. For example, there could be a 
POSIX module, as well as a VXWORKS or a DSP BIOS 
[3] which implements operating systems services by di- 
rectly using OS application programme interfaces or 
compensates for a lack of OS functionalities for imple- 
13 menting them. 

[0073] With regard to software requirements, the 
modular approach permits a module to add JAVA virtual 
machine functionality or native methods to respective 
application requirements by implementing, completing, 
20 tracking or intercepting all services or types. For exam- 
ple, a module could implement services and types to 
provide a class loader Optionally, a module could com- 
plete a type. For example, a thread module could add a 
private mutax on object type and class type without 
25 modifying other modules which use these types. Hooks 
can be added on any service, so that for example a 
benchmark/profile/debug module could trace every 
service in the JAVA virtual machine. 
[0074] Any service may be intercepted, for example 
30 a module could intercept the class access service to add 
multiprocessing by cloning static fields and monitors of 
classes as described in reference [4]. Since the speci- 
fication of the JAVA platform is subject to evolution, for 
example a JAVA virtual machine compliant with CLDC 
specification has to be CDC compliant (class load sup- 
port, floating support, byte code verifier support, etc.), 
new or extensions of a JAVA virtual machine specifica- 
tion can significantly change the design of several ele- 
ments of the JAVA virtual machines. The initial effort for 
obtaining a JAVA virtual machine for a first target is sig- 
nificant since the first decomposition of the modules is 
non trivial and the initial design can take a long time. 
However, once this effort has been expended, then fur- 
ther advantage may be taken of the modularity decom- 
position in order to generate JAVA virtual machines for 
further target processors. 

[0075] Embodiments in accordance with the present 
invention for developing and providing a JAVA virtual 
machine require the use of several tools, and are limited 
in respect of the coding restrictions in the implementa- 
tion of module services. Advantageously, new tools may 
be developed in order to improve the implementation of 
modules. 

[0076] The integration of hardware and software for 
the design of respective modules requires strong skills 
both in hardware design, especially on an analysis of 
the side effects introduced by a treatment on architec- 
ture, in tool chains (It is necessary to support a new lan- 
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guage, or to adapt MDE tool according to a language 
facility), in the operating system (in order to manage the 
JAVA virtual machine efficiently through the operating 
system by choosing the best facilities available) and al- 
gorithmically for op code realisation. The foregoing chal- 
lenges exist for other non-modular JAVA virtual ma- 
chines. Embodiments in accordance with the present in- 
vention, differ from conventional JAVA module ma- 
chines and their design in that it provides the possibility 
for the designer to exploit their skills in order to deter- 
mine the best trade-off for the JAVA virtual machine, to 
run on a multi-processor system environment or option- 
ally on a single processor 

[0077] An embodiment in accordance with the 
present invention comprises a JAVA virtual machine de- 
signed using a modular approach. 
[0078] In a preferred embodiment, the JAVA virtual 
machine is decomposed in several modules classified 
in six categories as illustrated in Table 1 of Figure 4. The 
six categories are arithmetic, JAVA frame, control flow, 
object, class and miscellaneous. Each module is given 
a name indicative of the function that it is performed. For 
example, the module which handles the representation, 
operations, and conversion of JAVA integers, is termed 
"integer". In a particu lar embodiment, the hardware sup- 
ported is a PENTIUM 32 bit core processor family. Ad- 
ditionally, the Texas Instruments DSPc55x family, which 
is a 16 bit word addressable processor, is also support- 
ed. In the preferred embodiment, most modules are writ- 
ten in ANSI C compiler, a few are written with the GNU 
C features and Tl DSP: C55x. Modules may also be im- 
plemented in PENTIUM and DSP assembly language, 
and also in DSP optimised C compiler for increasing the 
efficiency of bit code execution. 
[0079] A third embodiment supports operating sys- 
tems such as a POSIX general operating system 
(LINUX, WINDOWS PROFESSIONAL/98/2000) but al- 
so a real time operating system with POSIX compatibil- 
ity (VXWORKS). Optionally, each module may be adapt- 
ed depending on VXWORKS features, leaving the 
POSIX compatibility for that case. 
[0080] From the application point of view, the CLDC 
specification is supported. Additionally, floating point op- 
erations are supported as well as authorised class load 
execution in order to permit the downloading of applica- 
tions via a network for example. Consequently, the pre- 
ferred embodiment may be considered to be closer to 
CDC than CLDC. 

[0081] There will now be described an implementa- 
tion for a target processor from a commonly used family 
in embedded systems, i.e. the C55x from the Texas In- 
struments DSP 

[0082] A DSP is a dedicated processor for a digital 
signal processing. In spite of its limitation when used as 
a general microprocessor, its large usage in embedded 
systems and also some interesting features means that 
the running of a partial or a full JAVA virtual machine on 
such a hardware platform is not a meaningless propos- 



al. In the following section the hardware features of the 
Tl C55x family, and its tool chain characteristics in op- 
erating systems are briefly described. Further details 
may be found from reference [3]. 

s [0083] The low power C55x family of Texas Instru- 
ments have up to six address buses, one programme 
bus and five data buses allowing one 32-bit programme 
read, three 16-bit data read and two 16-bit data write 
buses for simultaneous operations during one cycle. 

10 The status base is only word addressable. There are 
some 59 registers from 7-bit to 40-bit, a 40-bit ALU and 
barrel shifter, and a multiply/accumulate unit. Finally, 
there is a local single or double access memory on chip. 
[0084] The C55x family of processors is composed of 

15 a pre-processor, a ANSI C compiler, a C optimiser, an 
assembler and a linker. The ANSI C compiler has a lim- 
ited C/assembler mixed support, in lining support, and 
32-bits IEEE floating points support. The ANSI C com- 
piler also has uncommon data types since it manages 

20 characters of 16-bits, with long characters of 40-bits, 
function pointers of 24-bits, and data pointers of 1 6 bits 
(small memory model) or23-bits (large memory model). 
[0085] A very basic operating system is available on 
the Tl C55x. It is a system that permits interrupt man- 

25 agement, inputs/outputs from/2 the chip set, and also 
offers the abstraction of task and permits the use of pre- 
emptive fix scheduling with a few number of tasks. No 
abstraction of address space is provided and few library 
calls are supported. This operating system is very small 

30 and is adapted to the Tl DSP C55x instruction set. 
[0086] In the preferred embodiment, the interpretation 
engine of the illustrative JAVA virtual machine is referred 
to as a motor module. The motor module is in charge of 
decoding the byte code in order to call the appropriate 

35 function to perform the op code operation associated 
with the byte code. In a first implementation, a classical 
loop is used to fetch one op code, to decode it with a C 
switch statement (or similar statement for another im- 
plementation language) and to branch to the right piece 

40 of code. In a second implementation, so-called threaded 
code, reference [5], is used to translate, prior to execu- 
tion, the original byte code by sequence of addresses 
which point directly to op code implementation. At the 
end of each code implementation, a branch to the next 

45 address is performed and so on. Such an implementa- 
tion avoids the decoding phase of the switch solution 
described above, but causes an increase or expansion 
in the amount of codes. 

[0087] The Applicants have conducted experiments 
50 with regard to the two implementations described above 
for the motor modules. In the first experiment, a 
switched motor module was coded with ANSI C; whilst 
for the second implementation a threaded motormodule 
was implemented with GNU C (although this implemen- 
ts tatlon requires the GNU C's label as values feature). 
These two implementations of the motor module were 
run on the well-known CISC 32-bit Intel Pentium II proc- 
essor. Secondly, the two implementations were run on 
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a Tl DSP C55x processor for which motor was merely 
compiled and switched. Due to the absence of GNU C 
features on the Tl tool chain, assembler statements 
were added to achieve a threaded motor. 
[0088] Table 2 illustrated in Figure 5 summarises the 
number of cycles used to execute one loop of a JAVA 
class-file to compute f ibonacci numbers and the number 
of memory bits to store the byte code (translated or not). 
[0089] With the Intel Pentium II, the threaded motor 
saves 19% of cycles, whereas for the Tl DSP C55x, its 
saves 62% of cycles. This difference in speed is very 
important, since there is more than three times the sav- 
ing for the Tl DSP C55x. On the other hand, the Pentium 
N has a memory overload of 400% between the thread- 
ed motor and the switch motor because, in the first case, 
one op code is represented by one byte, and in the latter 
case, with four bytes (one pointer). But on the Tl DSP 
C55x the memory overhead is only 200% because of 
the representation of one op code with two bytes due to 
the 1 6-bit character type. A modified switch motor with- 
out memory overhead (labelled as switch 2) which takes 
the high or low byte of one word depending on the pro- 
gramme counter parity, takes more than twice the 
number of cycles of a classic switched motor. 
[0090] As can be clearly illustrated by the foregoing, 
the gain obtained by an optimisation for one particular 
processor is not necessary the same as the other. 
Therefore, it is optimistic to believe that optimisation can 
be achieved in a completely portable code. Thus, com- 
piling a portable source of a JAVA virtual machine with- 
out fully understanding the target processor or proces- 
sors could result in poor performance or unwitting and 
undesired memory expansion. 
[0091] An advantage of the modular approach de- 
scribed herein Is that it allows several implementations 
of the same module to be provided for experimentation 
with different strategies on different target processors, 
or to focus on one particular module among existing ge- 
neric portable modules. 

[0092] Although two specific processor families have 
been referred to in describing implementation of the in- 
vention, namely the Pentium II processor and the Tl 
DSP C55x family of processors, it will be readily appar- 
ent to the person of ordinary skill from the preceding 
general description that the teaching may be applied to 
other processors, for example shared memory multi- 
processor or architectures. 

[0093] Embodiments of the invention provide an easy 
way to add modules between two other ones transpar- 
ently. Moreover, modules may be easily adapted to 
JAVA virtual machines for embedded systems, such that 
the JAVA virtual machine can be adapted to new fea- 
tures depending upon the application requirement. This 
permits the taking into account of hardware and soft- 
ware evolution. As an example, the management of mul- 
timedia applications taking into account energy con- 
sumption may be included as a module or modules with- 
in embodiments of the invention, reference [8]. Moreo- 



ver, the reusability of existing module implementation 
limits the adaptation of few modules only on a new em- 
bedded system and that reduces development cost. Fi- 
nally, the independence between modules increases its 

5 ability of overall JAVA virtual machine, and also the 
maintenance cost of the JAVA virtual machine software. 
[0094] In view of the foregoing description it will be 
evident to a person skilled in the art that various modi- 
fications may be made within the scope of the invention. 

10 [0095] Evidently, further modules may be designed 
and provided for implementation in accordance with the 
present invention. 

[0096] Insofar as embodiments of the invention de- 
scribed above are implementable, at least in part, using 
15 a software-controlled programmable processing device 
such as a Digital Signal Processor, microprocessor, oth- 
er processing devices, data processing apparatus or 
computer system, it will be appreciated that a computer 
program for configuring a programmable device, appa- 
20 ratus or system to implement the foregoing described 
methods is envisaged as an aspect of the present in- 
vention. The computer program may be embodied as 
source code and undergo compilation for implementa- 
tion on a processing device, apparatus or system, or 
may be embodied as object code, for example. The 
skilled person would readily understand that the term 
computer in its most general sense encompasses pro- 
grammable devices such as referred to above, and data 
processing apparatus and computer systems. 
[0097] Suitably, the computer program is stored on a 
carrier medium in machine or device readable form, for 
example in solid-state memory or magnetic memory 
such as disc or tape and the processing device utilises 
the program or a part thereof to configure it for operation. 
The computer program may be supplied from a remote 
source embodied in a communications medium such as 
an electronic signal, radio frequency carrier wave or op- 
tical carrier wave. Such carrier media are also envis- 
aged as aspects of the present invention. 
[0098] The scope of the present disclosure includes 
any novel feature or combination of features disclosed 
therein either explicitly or implicitly or any generalisation 
thereof irrespective of whether or not it relates to the 
claimed invention or mitigates any or all of the problems 
addressed by the present invention. The applicant here- 
by gives notice that new claims may be formulated to 
such features during the prosecution of this application 
or of any such further application derived therefrom. In 
particular, with reference to the appended claims, fea- 
tures from dependent claims may be combined with 
those of the independent claims and features from re- 
spective independent claims may be combined in any 
appropriate manner and not merely in the specific com- 
binations enumerated in the claims. 
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Claims 




1 . A method for generating program code for translat- 
ing high level code into instructions for a target proc- 
essors, the method comprising: 

50 

determining a program code characteristic cor- 
responding to a target processor; 
deriving one or more program code modules in 
accordance with said desired program code 
characteristic; and 55 
generating program code for translating high 
level code into instructions for said target proc- 
essor from said one or more program code 



A method according to any preceding claim, where- 
in: 

said step of determining comprises determining 
respective program code characteristics for re- 
spective ones of a plurality of target proces- 
sors; 

said step of deriving comprises deriving re- 
spective program code modules in accordance 
with said respective program code characteris- 
tics; and 

said step of generating comprises generating 
program code for translating high level code in- 
to instructions for said target processors from 
said program code modules. 

A method according to any preceding claim, where- 
in said step of deriving comprises selecting one or 
more pre-defined program code modules in accord- 
ance with said program code characteristic from a 
plurality of available program code modules. 

A method according to any preceding claim, where- 
in said program code provides a virtual machine for 
said target processor or processors. 

A method according to any preceding, wherein said 
program code comprises JAVA program elements. 

A software tool for creating program code for trans- 
lating between high level code and instructions for 
a target processor, comprising software tool ele- 
ments for: 

determining a program code characteristic cor- 
responding to a target processor; 
selecting one or more predefined program code 
modules in accordance with said program code 
characteristic; and 

forming program code for translating high level 
code into instructions for said target processor 
from said selected one or more predefined pro- 
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gram code modules. 

10. A software tool according to claim 9, for creating 
program code for translating between high level 
code and instructions for one of a plurality of target 
processors. 

11. Data processing apparatus for creating program 
code for translating between high level code and in- 
structions for a target processor, the data process- 
ing apparatus being configured to: 

determine a program code characteristic corre- 
sponding to a target processor identifier input 
to said data processing apparatus; 
derive one or more program code modules in 
accordance with said program code character- 
istic; and 

create program code for translating high level 
code into instructions for said target processor 
from said derived one or more program code 
modules 

12. Data processing apparatus according to claim 11, 
configured for creating program code for translating 
between high level code and instructions for one of 
a plurality of target processors. 

13. Program code comprising at least one program 
code module of a plurality of program code modules 
for translating between high level code and instruc- 
tions for a target processor, said at least one pro- 
gram code module corresponding to a characteris- 
tic of said target processor and being selected from 
said plurality of program code modules. 

14. Program code comprising at least two program 
code modules for translating between high level 
code and instructions for respective ones of at least 
two target processors. 

15. Program code according to claim 14, said at least 
two program code modules being selected from a 
plurality of predefined program code modules. 

16. Program code according to any one of claim 13 to 

15, comprising an agglomeration of two or more 
program code modules. 

1 7. Program code according to any one of claims 1 3 to 

16, for providing a virtual machine for said target 
processor or processors. 

18. Program code according to any one of claims 1 3 to 

17, said program code comprising JAVA program 
elements. 

19. A processor, configured in accordance with pro- 



gram code comprising at least one program code 
module of a plurality of program code modules, for 
translating between high level code and instructions 
for a target processor, said at least one program 
5 code module being in accordance with a character- 
istic of said target processor and selected from said 
plurality of program code modules. 

20. A processor, configured by program code compris- 
10 ing an agglomeration of two or more program code 

modules of said plurality of said program code mod- 
ules. 

21 . Program code according to any one of claims 1 3 to 
f s 1 8, forming a virtual machine for a target processor. 

22. Program code according to claim 21 , wherein said 
virtual machine is a JAVA virtual machine. 

20 23. A system comprising a first and second processor, 
said first and second processor configured in ac- 
cordance with program code comprising at least 
two program code modules, wherein the first of said 
at least two program code modules is arranged to 
25 translate high level code to instructions for said first 
processor and a second of said at least two program 
code modules is arranged to translate high level 
code to instructions for said second processor. 

30 24. A computer program comprising computer program 
elements for configuring a computer to implement 
the method of any one of claims 1 to 8. 

25. A computer program comprising computer program 
35 elements translatable for configuring a computer to 

implement the method of any one of claims 1 to 8. 

26. A carrier medium carrying a computer program ac- 
cording to claim 24 or 25. 
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Module I Description 



Arithmetic 


integer 
long 
float 
double 


Representation, operations and conversion of Java int 
Representation, operations and conversion of Java long 
Representation, operations and conversion of Java float 
Representation, operations and conversion of Java double 




Java Frame 


local 
stack 


Local variables management and access 
Stack management and access 




Control Flow 


motor 

branch 

exception 


Interpretation engine 

Branching and subroutine 

Exception management and branching 


! Object 


object 

field 

array 

method 

interface 

string 


Representation and operations on object and reference 
Representation of 'small' type and field access 
Representation and operations on array and element 
Method invocation and parameters passing 
Interface management 
Internal string and Java string representation 



Class 


cirepos 


Class repository 


load 


Class loader manager 



Misc. 


jni 


Java Native Interface support 


thread 


Thread and monitor support 



Table 1 : Modular decomposition of JVM p jg 4 
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